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ABSTRACT 

IPv6 over Low power Wireless Personal Area Network (6LoW- 
PAN) is an emerging technology to enable ubiquitous loT 
services. However, there are very few studies of the per¬ 
formance evaluation on real hardware environments. This 
paper demonstrates the feasibility of 6L0WPAN through 
conducting a preliminary performance evaluation of a com¬ 
modity hardware environment, including Bluetooth Low En¬ 
ergy (BLE) network. Raspberry Pi, and a laptop PC. Our 
experimental results show that the power consumption of 
6L0WPAN over BLE is one-tenth lower than that of IP over 
WiFi; the performance significantly depends on the distance 
between devices and the message size; and the communica¬ 
tion completely stops when bursty traffic transfers. This 
observation provides our optimistic conclusions on the fea¬ 
sibility of 6L0WPAN although the maturity of implementa¬ 
tions is a remaining issue. 
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1. INTRODUCTION 

The Internet of Things (loT) is an IT system based on a 
network of smart objects embedded with a sensor, software, 
and connectivity to exchange data with service providers. 
In the vision of Trillion Sensors Universe [^, for example, 
a tremendous amount of smart objects will be deployed ev¬ 
erywhere on the earth, and each of them has connectivity to 
the Internet, either directly or indirectly through gateways. 
To provide such a ubiquitous connectivity with several re¬ 
strictions to power, memory space, network bandwidth, and 
processing resources , IPv6 over Low-power Wireless Per¬ 
sonal Area Network (6L0WPAN) which is standardizing 
by IETF, is a promising technology. 
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In terms of the link layer, several low-power wireless tech¬ 
nologies, including ZigBee/IEEE 802 . 15 . 4 , Bluetooth Low 
Energy, and Wi-SUN, have been developed for supporting 
loT applications and services. Bluetooth Low Energy (BLE) 
or Bluetooth Smart aims at enabling low-cost sensors to 
exchange data for short distance, and it has a wide range 
of applications, including smart watches, home electronics, 
location-based services such as Apple’s iBeacon and Google’s 
Eddystone. The Bluetooth specification version 4.1 or newer 
is required for IPv6 over BLE links [^. Although the stan¬ 
dardization process is ongoing, some operating systems have 
already supported it in advance. 

In this paper, we demonstrate the feasibility of 6L0WPAN 
over BLE through conducting experiments on a commod¬ 
ity hardware environment. Our contribution is a prelimi¬ 
nary performance evaluation of 6LowPAN over BLE, includ¬ 
ing the power consumption comparing with both wired and 
wireless Ethernet technologies, the impact of the distance 
between devices and the message size on the throughput, 
and the application performance based on MQTT. 

The rest of the paper is organized into the following sections: 
Section presents the overview of a network protocol stack 
supporting loT services. Section shows our experimental 
results in a commodity software and hardware environment. 
Section demonstrates a simple MQTT application as a 
use case of loT services, and finally Section summarizes 
the paper and briefly mentions future work. 

2. lOT PROTOCOLS 

Figure shows a typical 6L0WPAN protocol stack from the 
physical layer to the application layer. Though 6L0WPAN 
is originally designed for IEEE 802 . 15 . 4 -based networks [^, 
currently 6L0WPAN over BLE is under the process of stan¬ 
dardization at IETF [^. The physical bit rate of BLE is 
up to 1 Mbps, and the effective throughput is about one- 
third of it. BLE has two roles of devices: a master and a 
slave. A slave device broadcasts advertise messages until a 
master detects it. After the link layer connection establish¬ 
ment, 6L0WPAN initialized the network interface, and IPv6 
communication between them is ready to start. 

6L0WPAN is an adaptation layer protocol in the middle of 
a link layer and a network layer, and it allows the trans¬ 
mission of IPv6 datagrams over IEEE 802 . 15.4 or BLE net- 
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Figure 1: 6 L 0 WPAN protocol stack 


works. Precisely speaking from the viewpoint of the BLE 
network, 6L0WPAN works on top of the Logical Link Con¬ 
trol and Adaptation Protocol (L 2 CAP) layer. IPv6 requires 
to transmit datagrams of 1280 bytes or larger, and the min- 
imnm header size is 40 bytes. However, the physical packet 
size of BLE is up to 47 bytes. 6L0WPAN fills the gap by 
employing several features including header compression and 
fragmentation. Several header compression schemes are de¬ 
fined, and the proper scheme is nsed for each IPv6 address 
type such as a link-local address and a nnique local address. 
At network interface initialization, a link-local address based 
on the 48 -bit BLE address is automatically assigned to the 
device. In this case, IPv6 header can be compressed to only 2 
bytes. However, applications cannot use a link-local address, 
and a non-link-local address have to be assigned to the net¬ 
work interface. In this case, IPv6 header can be compressed 
to 12 or 20 bytes. 

Application protocols layer on top of transport protocols. 
Table [^briefly compares three popular application protocols 
suitable for communication in machine-to-machine (M 2 M) 
and loT: MQTT (^, MQTT-SN [^, and CoAP [^. Mes¬ 
sage Queuing Telemetry Transport (MQTT) is a pub¬ 
lish/subscribe messaging transport protocol, ^n MQTT 
system contains three roles: broker, publisher, and sub¬ 
scriber. A broker is a medium for message exchanging among 
clients. A publisher transfers the message that be refer¬ 
enced by topic. A subscriber waits for messages that re¬ 
lated to the topic. If the topic that a subscriber attend 
was changed, the message is distributed to the subscribers. 
MQTT also provides three-level QoS for delivering messages 
between clients and brokers: “at most once”, “at least once”, 
and “exactly once”. MQTT for Sensor Network (MQTT- 


SN) is a lightweight variant of MQTT for low bandwidth 
and high failure networks, and devices with significant re¬ 
source constraints. It does not require TCP and security 
features. Usually, MQTT-SN gateways transfer MQTT- 
SN messages to an MQTT broker. Constrained Applica¬ 
tion Protocol (CoAP) is an HTTP-like transport pro¬ 
tocol based on the Representational State Transfer (REST) 
model. Servers make resources available under a URL, and 
clients access these resources using methods such as GET, 
PUT, POST, and DELETE. Unlike HTTP, CoAP is based 
on UDP and the encoding is binary form. 

The rest of the paper shows MQTT over 6L0WPAN because 
we can use several well-designed and open source MQTT 
implementations as shown in Table 

3. EXPERIMENT 

To demonstrate the feasibility of 6L0WPAN over BLE, we 
have conducted two experiments. This section shows the 
performance evaluation including the power consumption 
and the application-level performance using MQTT while 
the next section demonstrates a use case of MQTT over 
6L0WPAN. 

3.1 Experimental setting 

We have built a minimum 6L0WPAN environment which 
consists of ThinkPad X 230 t (X 230 ) and Raspberry Pi model 
B-|- (RasPi). Table summarizes the specifications. Linux 
operating system is running on both X 230 and RasPi, where 
the kernel 3.18 and later have already supported 6L0WPAN 
over BLE. 

To evaluate the performance of MQTT on a 6L0WPAN en¬ 
vironment, MQTT version 3.1 compliant implementations 
were used as follows. Mosquitto [3 is an open source bro¬ 
ker implementation written in the C language. We used the 
version 3 . 1 . Paho is an open source client library and 
supports multiple programming languages such as C, Java, 
and Python. We used version 1.1 and, both our benchmark 
and application programs were written in C. 

We used unique local IPv6 addresses in MQTT experiments. 
After establishing 6L0WPAN connection, a link-local IPv6 
address is automatically assigned to the BLE device as de¬ 
scribed in Section We also assigned a unique local IPv6 
address to each device because Paho C library cannot use a 














Table 2: Hardware and Software Specifications 



ThinkPad X230t 

Raspberry Pi model B-f 

CPU 

Intel Core i7-3520M@2.90 GHz 

Broadcom BCM2835 (ARM1176JZF-S)@700 MHz 

Memory 

16 GB 

512 MB 

Disk 

SSD 256 GB 

microSD Card 32 GB 

Ethernet 

BLE 

WiFi 

Intel 82579LM 

I-O DATA USB-BT40LE 

I-O DATA WN-G150UMK 

Microchip LAN9512 

OS 

Ubuntu 14.04.2 LTS 64bit 

Raspbian GNU/Linux 7 

Kernel 

3.18.0-031800-generic 

3.18.14-b 


Table 3: Comparison of power consumption among a 
combination of network devices and workloads [mA] 
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0.04 
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0.24 

0.04 


iperf (58.3 Mbps) 

0.27 

0.07 


idle 

0.29 

0.09 

WiFi 

ping 

0.30 

0.10 


iperf (32.2 Kbps) 

0.32 

0.12 


idle 

0.21 

0.01 

BLE 

ping 

0.21 

0.01 


iperf (5.84 Kbps) 

0.21 

0.01 


link-local IPv6 address to transfer messages. 


3.2 Benchmark 

3.2.1 Power Consumption 

We measured the power consumption of RasPi on several 
conditions, that is, the combination of three network de- 
vices(wired Ethernet, WiFi, and BLE) and three workloads 
(idle, ping, and iperf benchmark program). The distance 
between devices is 0 meter. RasPi is supplied 5V power 
from USB cabling. To measure the power consumption, we 
observed current on a USB power line by Sanwa PC700 mul¬ 
timeter. 

Table 1^ shows that the absolute power consumption of each 
case and the increase over the baseline, that is idle without 
any network devices. The power consumption of 6L0WPAN 
over BLE is one-tenth lower than that of IP over WiFi. BLE 
takes lowest power consumption among three devices, and 
the increase over the baseline is only 0.01 mA. On the other 
hand, WiFi takes the highest power consumption. In terms 
of the transferred per Joule, however, BLE is not efficient 
because the throughput is quite small comparing with the 
theoretical link bandwidth, which is 1 Mbps. We consider 
the implementation may not be mature enough. 

3.2.2 Distance between devices 

We measured the impact of the distance between 6L0WPAN 
devices on the application-level performance, that is, how 
many MQTT messages can be published from a client to 
the broker for one second, where the distance is varied from 
0 to 20 meters. Each benchmark trial takes 10 seconds. This 
experiment was conducted in a corridor without any blind 
spots and devices were put on the floor. 
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Figure 2: Latency and MQTT throughput while 
varying the distance between devices 


Figure shows results of the round trip latency and the 
MQTT throughput. The MQTT throughput linearly de¬ 
creases as the distance increases. Finally, the communica¬ 
tion failed where the distance is over 20 meters. It is because 
that MQTT runs on top of TCP and TCP performance 
degrades as the round trip time increases. We observed a 
few TCP retransmissions during this experiment, where the 
number of TCP retransmissions does not depend on the dis¬ 
tance. Note that we obtained each result separately, and the 
latency fluctuated; therefore the correlation between them 
is not so evident from Figure 


3.2.3 Message size 

We also measured the impact of the message size on the 
MQTT throughput where the message size is varied from 1 
to 256 bytes. The distance between devices is 0 meter. Each 
benchmark trial ran in the period of 10 seconds. 

Figure presents the relationship between the throughput 
and the message size. The message size is a significant fac¬ 
tor for the performance. The throughput decreases in pro¬ 
portion to the message size, and it suddenly drops between 
16-byte and 32-byte messages. It can be caused by frag¬ 
mentation, where the message is fragmented into multiple 
BLE packets. This result leads that application program¬ 
mers should keep the message size as small as possible to 
get better performance. 





















Figure 3: MQTT throughput while varying the mes¬ 
sage size (log-log plot) 


Table 4: Topics of USB-powered light application 


Topic 

Description 

light / control 

This topic is used to turn the light on and 
off. The message should contain “on” or 
“off”, otherwise the client returns an error. 

light/status 

This topic is used to get the status of the 
light. It returns “on” or “off”. 


4. USE CASE: USB-POWERED EIGHT AP¬ 
PLICATION 

We have implemented a simple MQTT application as a use 
case of loT services. This application allows the users to 
control the USB-powered light from remote computers, and 
it is quite simple but enough for demonstrating the usability 
and the functionality of MQTT. 

This application consists of two clients: device and con¬ 
troller. A device client is running on a computer that has a 
target device, e.g., USB powered-light, and controls it. On 
the other hand, a controller client controls the target de¬ 
vice and get the status remotely. These clients exchange 
the MQTT message via a broker, and they act as some¬ 
times subscribers and at other time publishers. We define 
two topics: “light/control” and “light/status”, as shown in 
Table The former is used to turn the power on and off; 
the latter is used to get the power status. Besides, to keep 
the latest power status on the broker, we set messages for 
topic “light/status” to be retained. 

This application is written in Python with the Paho Python 
library. To control the power supply of each USB port, we 
use hub-ctrl on a controller client. In this experiment, 
device and controller clients ran on RasPi and X230, respec¬ 
tively; the broker ran on X230. 

We found a critical problem that hub-ctrl turns off all of USB 
ports on RasPi. Therefore, the “light/control off” message 
turns off not only the light but also the BLE USB dongle. By 
using GPIO instead of hub-cntl, we can control AC power 
supply to external electronics products like this application. 


5. CONCLUSION AND FUTURE WORK 

GLoWPAN is a promising technology in the loT era. To 
demonstrate the feasibility, we have conducted a prelimi¬ 
nary performance evaluation of a commodity hardware envi¬ 
ronment, including Bluetooth Low Energy (BLE) network. 
Raspberry Pi, and a laptop PC. Our experimental results 
show that the power consumption of GLoWPAN over BLE is 
one-tenth lower than that of IP over WiFi; the performance 
depends on the distance between devices and the message 
size. Since this evaluation is limited, a comprehensive eval¬ 
uation will be shown in a future publication. 

Besides, we have observed that the implementation on the 
Linux is not mature enough. Although our MQTT bench¬ 
mark generates a none realistic workload, we found a serious 
issue as described below. Our MQTT benchmark have often 
failed, and any packets do not go through the network after 
that until rebooting machines. This issue was not observed 
with wired and wireless Ethernet. To pursue the cause, we 
have updated the Linux kernel from the version 3.18 to 4.0. 
However, the situation does not change. A stable implemen¬ 
tation of GLoWPAN over BLE is a future work. 

Privacy is another big concern for loT services. We plan 
to develop MQTT services using homomorphic encryption 
that allows computations to be carried out on encrypted user 
data. Such technology can extend the range of application 
of loT and GLoWPAN. 
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